Subject: Missing link?

From: "Mel Jones (Tie: 444-4363)" <[email-masked]>
Date: Mon, 15 Nov 93 13:50:34 EST

Ref:  Your note of Thu, 11 Nov 1993 18:08:43 -0800

Frank:  Thanks for the note with the questions -- sorry for my delay in
responding, but I was out of the office the second half of last week.

I've broken up your questions into separate paragraphs below and added
answers (marked with >).  I hope this clarifies things some.

Regards,
Mel

- - - - - - - - - text of Frank's note, with answers - - - - - - - - - -
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
Date: Thu, 11 Nov 1993 18:08:43 -0800
To: [email-masked]
From: [email-masked] (Frank Chin)
Subject: Missing link?
X-Mailer: <PC Eudora Version 1.1a10>

I am a little bit confused and lost in this "CPI-C Changes for
Use of Distributed Directory".

The document describes enhancements to CPI-C that are required
for use of a distributed directory.   It talks about Distinguished Name,
Program Function Identifier, X.500 environment, DCE environment,
etc.  I don't know much about X.500 and DCE but as far as I know
that they are currently available on TCP/IP network and  NOT
available on the APPN network. So, what does this mean? Does it
mean that a CPI-C program which uses distributed directory
service can only be on TCP/IP network?? (Dual communication
protocol stacks with both TCP/IP and APPN coexisted in one box
does not sound a good idea, does it?)

>  At the September meeting, there was a request for broader background
>  on directories.  Part of the difficulties we were having seemed to come,
>  at times, from different directory discussions using different terminology.
>  The first section of the paper was added strictly as an overview to give
>  a very quick tutorial on different directories and directory concepts.
>  Therefore, you are right that the overview discusses X.500 and DCE, but this
>  is strictly as background information.  The design point of the CPIC
>  directory changes was to allow whatever directory technology the
>  CPIC implementation had available.  Set_Partner_ID can be implemented
>  on top of a flat file if that is what the implementation wants to use;
>  alternatively, it could be placed on top of a distributed database.
>  It could also (obviously) be built on top of a full X.500-compliant directory.
>  But there is *no* requirement that a program using a distributed directory
>  be built on any particular type of directory (which might or might not be
>  tied to some particular type of network protocol TCP/IP).
>
>  Some implementations may choose to provide the function with X.500 or DCE --
>  particularly if, say, they *have* a DCE implementation to exploit --
>  but the architecture design point is to allow any type of "distributed directory,"
>  where that term is used in the loosest possible fashion.  The minimum function
>  (discussed in section 1.2 and 1.2.2 in the 11/9 draft) gives a great deal of
>  flexibility in what the implementation uses.  Even implementations that have
>  access to full-function distributed directories like DCE will probably want to allow
>  "light-weight" directory support (so they *don't* pre-req a lot of costly
>  code).  A good example would be providing the DCE-specific local interface on
>  top of a common file available over a LAN -- it's not really distributed, but
>  it's not really expensive either......

Does it also mean that if this CPI-C program choose LU6.2 option
(instead of OSI-TP), then you need an "Multi-Protocol Transport
Network" so that it can access an X.500 or DCE-based distributed
directory???

>  I'm not sure what you're asking here -- the choice of the
>  protocol for the conversation (OSI or LU 6.2) has no
>  meaning/significance/connection at all to the type of the
>  underlying distributed directory.  CPIC doesn't care.  The CPIC
>  implementation will make use of whatever local directory
>  interface is available.  If you're asking "How does that local
>  directory communicate with its distributed 'partners'?", the
>  answer again is, CPIC doesn't care.
>
>  Now if you're asking, "How does a box that is only connected to
>  the network by LU 6.2 get access to DCE directory services?"
>  that's a completely different question, because it's more a
>  discussion of what directories are available and how have they
>  been implemented.  There's nothing to stop you from doing a DCE
>  implementation using LU 6.2  (or Netbios for that matter) as the
>  underlying transport, but right now most people have stuck with
>  using it over TCP/IP.  I think that's probably what you meant by
>  asking about "Multi-Protocol Transport Network" (MPTN) -- if a
>  system decided to use DCE, and the DCE implementation they used didn't
>  provide anything other than TCP/IP as the connection protocol,
>  you'd have to do something like MPTN (which would let a sockets
>  flow run over an SNA transport).  But that's all in the choice of
>  what you, the implementer, choose to do in providing a distributed
>  directory in your system.  You could just as easily provide the
>  minimum directory function (described in section 1.2.2) by
>  setting up a client and server connected with a CPIC conversation
>  -- the client would send requests for a particular name to the
>  server, which would then send back the data record.  CPIC doesn't
>  (and shouldn't) care.
>
Isn't true that APPC network node offers directory service?
What kind of directory service does it provide?
Does it provide directory service just for routing need?
Shouldn't it expand to provide "yellow-page" type directory
service?

>  I think you mean APPN network node here, not APPC.  If so, then
>  yes, APPN does have a directory, but it's a very specialized
>  function used by the lower network layers for routing only.  A 17
>  byte name gets passed in and the specific APPN routing
>  information comes out.  It is not a general-purpose directory, but
>  is very specific to the needs of APPN.  Expanding this directory
>  to include application-program data would be like (prepare yourself
>  for a bad analogy) using a two-seater Miata to move a Grand
>  Piano:  You might eventually manage it, but it would take a lot of
>  fun out of the driving . . . .
>
>  The reason is that the APPN directory has a
>  different design point:  It needs to be very fast and ensure
>  near-instantaneous updates because the directory data is being
>  used for network routing.  Another factor is the relative
>  size of the directory.  The total number of
>  entries in the APPN directory is actually quite small because max size
>  is bounded by the number of nodes
>  in the network.
>
>  By contrast, the design point of a directory that stores
>  application-program data (such as DCE) is quite different --
>  performance isn't as critical and the base assumption is for
>  a very large quantity of entries.  The size is orders of
>  magnitude larger than that for APPN.  (Take the total entries for
>  the largest APPN directory and multiply by the max number of
>  entries for application programs *per* system.....).  It also
>  assumes that those entries are not going to be changed very often
>  and updates of changes are not as critical as
>  they are for APPN.  Updates might be in terms of hours instead of
>  seconds.

Related issue:  I have received a copy of CPI-C version 2.0
Second Review Draft, it does not include the support of
distributed directory.  Will the support of distributed directory
be in CPI-C version 2.0?

> The latest draft (11/2)  contains everything that was at
> AP or CP as of the September meeting (which therefore excluded
> the directory material).  The plan is to get AP at the December
> meeting on the changes for directory (described in the 11/9 directory
> paper) and include them into the complete doc before sending it to
> X/OPEN.

If the answer is yes, then my next questions are: when are we
going to have a "final" version of CPI-C version 2.0? Are we
going to have it before it is submitted to X/Open for review?

> The goal is to have a "final" version available after the
> December CIW -- I think the tentative date is 12/9 for making the
> complete updated draft (with all AP/CP changes) available, but
> that date is contingent on what happens at the CIW, how much change,
> etc. etc.  The document will definitely be available to the CIW before
> it is sent to X/OPEN . . .  If you have more questions on that, the correct
> contact is Ajay Kshemkalyani.

- - - - - - - - - end of note - - - - - - - - - - -  - - - - - - - - - -